Detailed Explanation Of After-sales Service And Sla Guarantee For Hong Kong High-defense Servers

1.1 definition: hong kong high-defense server is a server environment for traffic cleaning and business protection against large traffic/large concurrent ddos attacks.
1.2 goal: ensure business continuity and reduce the risk of packet loss and business interruption.
1.3 role: geek after-sales is responsible for activation, monitoring, rapid response and sla compensation process, and the customer is responsible for providing business information and cooperation verification.

2.1 estimated bandwidth/pps: use the monitoring system or historical traffic statistics (peak values ​​in the past 30 days) to obtain the peak bandwidth and peak packet rate.
2.2 determine the strategy: if you are often attacked by large traffic, choose the "peak protection" or "burst cleaning + stable protection" package; if it happens occasionally, choose basic guarantee plus on-demand expansion.
2.3 submit information: prepare business domain name, origin site ip, port, business importance level, contact person and 24/7 phone number.

3.1 place an order: select the hong kong node and protection plan on the official website, fill in your real name/company information and upload the required qualifications (business license or id card).
3.2 payment and confirmation: save the order number and invoice information after online payment.
3.3 verification stage: geek after-sales service will confirm the origin ip, whitelist and emergency contact by phone or email.
3.4 activation confirmation: after receiving the "activation complete" email, perform the next step of pre-online inspection.

4.1 dns adjustment: point the domain name a record or load balancing to the access ip provided by anti-ddos pro (or cname point to the domain name provided by the supplier).
4.2 back-to-origin configuration: fill in the back-to-origin ip (the real ip of the origin site) in the control panel and set the port and protocol.
4.3 whitelist/blacklist: submit the management ip segments (such as operation and maintenance ip) and known malicious ip segments that are allowed to be accessed by the management interface.
4.4 functional test: execute curl, browser access, mtr/traceroute verification path, and save screenshots of the results as online records.

5.1 identify attacks: confirm the attack type by monitoring alarms (bandwidth sudden increase, syn/udp explosion, high error rate) and record the timestamp.
5.2 immediate work order: log in to the console to create a new "emergency work order - traffic cleaning" and fill in: attack start time, peak bandwidth/pps, target port, business impact, and return source ip.
5.3 cooperate with cleaning: temporarily offline non-essential services as recommended by engineers, enable rule blacklisting or protocol identification (such as syn restrictions, http flood signature).
5.4 switching plan: if necessary, start bgp/anycast switching or temporarily change the access ip to divert traffic according to sla permission.

6.1 work order title template: emergency|ddos|domain name/ip|start time (yyyy-mm-dd hh:mm)
6.2 example of work order subject: 1) target: example.com (or 1.2.3.4) 2) attack start: 2026-05-01 10:12 3) peak value: 800gbps, pps 12m 4) business impact: the website cannot be accessed/api 50% request failure 5) contact information: zhang san +86-1xx-xxxx-xxxx.
6.3 attachments: upload pcap, monitoring screenshots, and traceroute output.

7.1 common indicators: availability rate (for example: 99.95%), response time (for example: 5-minute emergency response), mitigation time (for example: starting cleaning within 30 minutes), maximum protection traffic (for example: supporting up to x tbps).
7.2 terms to review: compensation rules (how to deduct proportional deductions for excess availability), service exclusions (human factors, third-party link problems), evidence requirements (monitoring/work orders/routing logs need to be provided).
7.3 reading suggestions: mark the "response" and "mitigation" in the contract respectively, and record the timing points (alarm time, work order acceptance time, mitigation start time) as evidence for subsequent claims.

8.1 collect evidence: download monitoring curves, work order records, traceroute/bgp update logs, origin site access logs and package timestamp signatures.
8.2 submit a claim work order: select "sla claim" on the console, attach the evidence package and indicate the expected compensation (for example, calculated in proportion to the monthly fee).
8.3 follow-up and upgrade: if there is no clear reply within 48 hours, follow the upgrade path in the contract and send a copy to the after-sales manager/legal department; keep all emails and work order ids.
8.4 calculate compensation: calculate with reference to the compensation form in the contract and require the other party to issue settlement documents.

9.1 monthly inspection: check protection rules, update black and white lists, view traffic trend charts and export reports.
9.2 disaster recovery drill: conduct a switching drill (dns switching, bgp failover, back-to-source verification) every quarter and record the process time.
9.3 communicate with after-sales: regularly arrange 1:1 review meetings to share attack samples, request personalized rules, and optimize cleaning strategies.

q: how can i get traffic cleansed as quickly as possible after an attack? answer: immediately submit an "emergency ddos work order" on the console, mark the title as urgent and fill in the attack start time, peak value, and impact scope; at the same time, call the geeks on duty 24/7 and provide pcap or monitoring screenshots; temporarily switch dns/ip or enable bgp/anycast according to the engineer's instructions, and submit the required back-to-origin and authentication information. usually the engineer will start cleaning within the response time stipulated in the contract.

q: if the service does not meet the sla, how can i make a claim? answer: the first step is to collect evidence (monitoring charts, work order records, traceroute/bgp logs, origin site logs), the second step is to submit an "sla claim work order" on the console and attach the evidence package, and the third step is to wait for the other party's audit and request a settlement form as required by the contract; if the other party delays processing, escalate to the after-sales manager or legal team according to the contract and keep communication records for arbitration.

q: how to cooperate with geek after-sales service for a long time to optimize the protective effect? answer: establish a regular communication mechanism (monthly reports/quarterly drills), share attack samples and business priorities, apply for personalized cleaning rules and whitelist management, regularly evaluate protection bandwidth and billing models, and upgrade or adjust packages as needed; also designate fixed contacts and emergency contact lists to ensure rapid response when encountering anomalies.